Fullscreen modal sizes have a few flavors

I like that modalDialog() helps you find the appropriate value, but more and more I feel like throwing an error for invalid value unnecessarily breaks future-compatibility with changing sizes.

I think the behavior I'd prefer here in this case is:

1. If size is a known alias value, map to a specific class, e.g. "s" → modal-sm or "full" → modal-fullscreen.
2. If size doesn't already have the modal- prefix, prepend it, e.g. "sm" → modal-sm or "fullscreen-lg-down" → modal-fullscreen-lg-down

I'm going to bring this up internally to see what the rest of the Shiny team thinks before we move forward.

Primarily to support Bootstrap size aliases (they use sm, md, lg, etc. instead of the s, m, l used here in size). If they know about the full class and use modal-fullscreen-lg-down we wouldn't prepend modal- to the class.

I like that! 🙂

Hey! It's been ~2months, do you have any update, do you want me to put a draft PR for this?

I was thinking of two additional options.

Option 1

In order to keep the old implementation we probably could include full as it is right now (opinionated) but we could also add an additional optional parameter like size_class = NULL or something like that to override what size passes, or even passing it as part of ....
So then if it's not null then it will override the size parameter?

In that way we give control to the user but we don't lose the original implementation logic.

Option 2

1. Implement a basic non-exported .base_modal_dialog that passes all of the parameters we can actually pass to BS5's modals.
2. Rewrite modalDialog using the new interface of .base_modal_dialog keeping "hardcoded" some of the parameters that we currently we do not have a way to pass. No changes to the API
3. Write custom_modal/modal_extended/modalDialogExtended, etc. that allows us to pass some of the new parameters handled by .base_modal_dialog. This will probably an exact copy of the base function, the different name is only to have a clear naming of what the base function is vs the exported one (the extended).

This last is more complex but gives us flexibility to update the base_modal_function as BS continues evolving without disrupting the old modalDialog one

I like more the 2 tho as I don't like the function overriding its own parameters, in fact I'd drop Option 1 😆